1. The Field of the Invention
The present invention relates to communication sessions, and more specifically, to using expressive session information to represent communication sessions in a distributed system.
2. Background and Relevant Art
Computer networks have enhanced our ability to communicate and access information by allowing one computer or device (hereinafter both referred to as a “computing system”) to communicate over a network with another computing system using electronic messages. When transferring an electronic message between computing systems, the electronic message will often pass through a protocol stack that performs operations on the data within the electronic message (e.g., packetizing, routing, flow control). The Open System Interconnect (“OSI”) model is an example of a networking framework for implementing a protocol stack.
OSI model breaks down the operations for transferring an electronic message into seven distinct “layers,” each designated to perform certain operations in the data transfer process. While protocol stacks can potentially implement each of the layers, many protocol stacks implement only selective layers for use in transferring data across a network. When data is transmitted from a computing system, it originates at the application layer and is passed down to intermediate lower layers and then onto a network. When data is received from a network it enters the physical layer and is passed up to higher intermediate layers and then eventually received at the application layer. The application layer, the upper most layer, is responsible for supporting applications and end-user processes. Another layer incorporated by most protocol stacks is the transport layer. An example of a transport layer protocol is the Transmission Control Protocol (“TCP”).
Often, when two computing systems desire to communicate with each other, for example, by transferring a number of electronic messages, the two computing systems will establish a communication session. To initiate the establishment of a communication session the two computing systems can exchange session options, such as, for example, a protocol, a session identifier (typically an integer value), and session semantics (e.g., data formats), that are subsequently used when transferring of electronic messages. Depending on the type of electronic message that is to be transferred, a communication session utilizing a particular protocol can be established. For example, when transferring an electronic mail message a Simple Mail Transfer Protocol (“SMTP”) communication session can be established. On the other hand, when transferring a Web page a HyperText Transfer Protocol (“HTTP”) session can be established.
To facilitate the exchange of session options, the two computing systems may participate in a handshake sequence as prescribed by a particular protocol that will be used to transfer electronic messages. For example, when a Session Initiation Protocol (“SIP”) communication session is to be established, the two computing systems may perform a SIP handshake sequence to exchange session options. Typically, handshake sequences for establishing a communication session are hard-coded, or “built into,” each protocol and include limited, if any, functionality to alter how session options are exchanged. Thus, an application designer may have no way to design an application layer process such that communication options can be exchanged in a way that differs from a hard-coded handshake sequence. This is unfortunate as the application designer is often in a better position to decide how a communication options should be exchanged for an application layer process.
Application layer processes can also be prevented from altering handshake sequences (in part due to the configuration of protocol stacks) used to establish communication sessions because these handshake sequences often operate at lower layers of a protocol stack. Application layer processes are typically not designed (or configured) to alter functionality at lower layers of a protocol stack. Thus, even for handshake sequences that are somewhat configurable, an application layer process may still be prevented from altering handshake sequence functionality. For example, a Web browser may have no way to access or control the selection of a TCP session identifier. Further, even if the Web browser were to access the TCP session identifier, the TCP session identifier would have little, if any, meaning to the Web browser.
It may be that an application designer desires for a particular distributed application to always establish TCP communication sessions with a particular session identifier value (e.g., “1”). Alternately, it may be that the application designer desires for the particular distributed application to represent communication sessions through a session identifier that is more expressive than an integer value. Unfortunately, the application designer would typically be prevented from implementing either of these functionalities since TCP operates at the transport layer (and thus is below the application layer).
Further, many protocols used to establish communication sessions are point-to-point protocols that permit establishment of a communication session only between two connected points. However, these same protocols do not permit communication sessions to be directly established between two computing systems that are separated by intermediaries, such as, for example, by a number of intermediary computing systems in a routing path. Thus, multiple communication sessions may need to be established to facilitate the transfer of an electronic message between two computing systems that are not directly connected.
FIG. 6 is a prior art Figure illustrating client 601, intermediary 605, and server 602. In FIG. 6, communication session 612 can be established between client 601 and intermediary 605 based on communication options that are exchanged between client 601 and intermediary 605. Likewise, communication session 613 can be established between intermediary 605 and server 602 based on communication options that are exchanged between intermediary 605 and server 602. It may be that the communication options exchanged between client 601 and intermediary 605 differ from the communication options exchanged between intermediary 605 and server 602. Thus, the session identifiers and session semantics of communication session 612 and 613 can differ. This can lead to processing inefficiencies when an electronic message is sent from client 601 to server 602.
Intermediary 605 may be required to maintain communication options (e.g., session identifiers) for both communication session 612 and communication session 613 and be able to compatibly translate between the differing communication options. Thus, when an electronic message is transferred from client 601, through intermediary 605, to server 602, intermediary 605 may expend resources translating the electronic message even though intermediary 605 is not the ultimate recipient of the electronic message. Further, even if the communication options of communication session 612 and communication session 613 are similar (or perhaps even identical), intermediary 605 may still be required to expend resources to establish and maintain two communication sessions.
Therefore systems, methods, computer program products, and data structures for using expressive session information to represent communication sessions would be advantageous.